在這 30 天裡面，我們增加維護性的手法事實上可以分三大類，如下圖 :

設計原則

這個基本上都是老身長談了，但是矛盾的點在於每個人的理解幾乎都不能算相同，所以這裡比較是去看各種書籍中寫的，然後最後在整合成我自已理解的版本，但就參考吧。

但會把設計原則放在前面是因為，後面幾乎每個實務上面對的東西，最後事實上都和設計原則惜惜相關，所以這東西還是要理解呢。

• Day-02: 設計原則 SOLID - SRP
• Day-03: 設計原則之 SOLID - ISP、DIP
• Day-04: 設計原則 SOLID - OCP、LSP
• Day-05: 耦合性三大原則 ADP、SDP、SAP
• Day 06 : 聚合性三大原則 - REP、CCP、CRP
• Day-07: 設計原則的小整理

但事實上還有一些小原則我沒說，但是我也覺得很重要的，就在這裡補充一下。

• DRY 原則（Don't Repeat Yourself
• KISS 原則（Keep It Simple, Stupid）
• YAGNI 原則（You Aren't Gonna Need It）

參考書籍與資料

• 無瑕的程式碼 敏捷篇：還原敏捷真實的面貌 (Clean Agile : Back to Basics)
• 軟體架構：困難部分 (Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures)
• Clean Architecture 實作篇：在整潔的架構上弄髒你的手 (Get Your Hands Dirty on Clean Architecture)
• 無瑕的程式碼－敏捷完整篇－物件導向原則、設計模式與 C# 實踐 (Agile principles, patterns, and practices in C#)

實務上 Code Review 會看的地方 ( 我覺得說建議比較好 )

這裡大部份比較專注在這個層級，雖然影響範圍沒有像架構一樣那麼大，但積少成多，如果你架構已經穩了，那你只要這些地方處理好，那你的系統在維護面上，我覺得一定可以說好 ~

這些比較拉回來實務面時 code review 會看的一些地方。

• Day-08: 實務時 Code Review 看的地方之 1 ( 基本 )
• Day-09: 實務時 Code Review 看的地方之 2 ( 好理解 )
• Day-10: 實務時 Code Review 看 Class 地方 1 (基本)
• Day-11: 實務時 Code Review 看 Class 地方 2 ( 封裝 )
• Day-12: 實務時 Code Review 時會看的地方 ( 錯誤處理 )

但我覺得這裡面最難的地方在於三點 :

1. 執行，要如何讓團隊在 PR Review 時都要在意這些地方。
2. 客觀與主觀，因為每個人對好維護的理解都不一樣。
3. 性能與維護的 TradeOff

至於要如何解 ~ 我也還不知道呢 ~

參考書籍與資料

• 笑談軟體工程：例外處理設計的逆襲
• 重構｜改善既有程式的設計, 2/e (繁中平裝版)(Refactoring: Improving The Design of Existing Code, 2/e)
• 設計重構：25個管理技術債的技巧消除軟體設計臭味 (Refactoring for Software Design Smells: Managing Technical Debt)
• Kent Beck 的測試驅動開發：案例導向的逐步解決之道 (Test-Driven Development: By Example)(TDD)
• Working Effectively with Legacy Code : 管理、修改、重構遺留程式碼的藝術 (中文版)
• 無瑕的程式碼－敏捷完整篇－物件導向原則、設計模式與 C# 實踐 (Agile principles, patterns, and practices in C#)
• 程式設計守則｜如何寫出更好的程式碼 (The Rules of Programming: How to Write Better Code)
• Good Code, Bad Code｜寫出高品質的程式碼 (Good Code, Bad Code: Think Like a Software Engineer)

軟體設計模式與方法

這裡比較偏向這個位置，這一塊比較算是設計模式那一塊，但量級比架構面還小一點，不會像架構要一堆東西一起用之類的，然後有很大一部份都是 Design Pattern 但因為寫的人太多了，所以這裡我只寫一些我覺得比較少出現，但是又非常重要的部份。

• Day-13: 契約式設計 ( DBC Design By Contract ) vs 防禦式程式設計( Defensive Programming )
• Day-14: 提升維護性與降低複雜度的好方法之 Domain Model
• Day-15: Domain Model 實務上面對的困境之 DDD Trilemma
• Day-16: DI 是什麼？深入探討 IoC、DIP 的關聯性與好處
• Day-17: DI 的設計模式與臭臭的味道
• Day-18: Typescript 編譯器守護者

然後這裡列一些我覺得寫的很棒的設計模式鐵人賽的文章與網路文章 :

• 什麼？又是／不只是 Design Patterns!-Piccolage
• 初探設計模式-Daniel Wu
• 以三十個需求的實作來學習設計模式
  refactoring-guru-design-patterns

參考書籍與資料

• Martin Fowler 的企業級軟體架構模式：軟體重構教父傳授 51個模式，活用設計思考與架構決策 (Patterns of Enterprise Application Architecture)
• 依賴注入：原理、實作與設計模式 Dependency Injection Principles, Practices, and Patterns 1st Edition
• TS 官網

軟體架構篇

這裡我事實上是以 Domain-Driven Design 為主軸，目前我覺得他應該是公認解決業務複雜變化的一種架構思想，而且他基本上也只是站在前人例如 OOAD、Domain Model 等肩膀上產生出來的，因此我這裡花了很多篇文章在談它的事情。

• Day-19: Domain-Driven Design 提升團隊合作與軟體維護性的關鍵 ( 概略 )
• Day-20: Event Storming 經驗談
• Day-21: Event Storming To Code
• Day-22: 好的軟體架構的特點 ( Base Clean Architecture + DDD )
• Day-23: Domain Event 之 Transactional OutBox 與 EventBus
• Day-24: Domain Driven Design 與 API 設計的難處
• Day-25: 如何設計與管理 Bounded Context
• Day-25: 如何設計與管理 Bounded Context
• Day-26: CQRS ( Command Query Responsibility Segregation )
• Day-27: 如何降低 Query 複雜性探索

參考書籍與資料

這裡有點多簡單分類一下，首先是最多的 Domain-Driven Design。

• 複雜軟件設計之道：領域驅動設計全面解析與實戰
• 中台架構與實現：基於 DDD 和微服務
• 領域驅動設計 : 軟件核心複雜性應對之道
• 領域驅動設計：軟體核心複雜度的解決方法 (Domain-Driven Design: Tackling Complexity in the Heart of Software)
• 領域驅動設計 業務建模與架構實務
• 實現領域驅動設計 (Implementing Domain-Driven Design)
• 實戰領域驅動設計：高效軟體開發的正確觀點、應用策略與實作指引 (Implementing Domain-Driven Design)
• 領域驅動設計學習手冊 (Learning Domain-Driven Design)

和其它。

• CQRS 命令查詢職責分離模式 (Command Query Responsibility Segregation)
• 軟體架構原理｜工程方法 (Fundamentals of Software Architecture: A Comprehensive Guide to Patterns, Characteristics, and Best Practices)
• 編寫程式的邏輯：如何用物件導向實作複雜的業務需求
• Clean Architecture 實作篇：在整潔的架構上弄髒你的手 (Get Your Hands Dirty on Clean Architecture)
• 企業級業務架構設計：方法論與實踐
• 架構真意：企業級應用架構設計方法論與實踐
• 軟體架構：困難部分 (Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures)
• 無瑕的程式碼－整潔的軟體設計與架構篇 (Clean Architecture: A Craftsman's Guide to Software Structure and Design)

高品質的特性與指標

最後的部份就是指標，因為自從當了 tech leader 後，我發現一個好的指標真的可以幫助一個團隊努力往前，例如你看到你的 duplicate code 比例，或是每個 sprint 產的 bug 量有下降，真的會讓人感覺有在前進的 fu，這也是為什麼我這次會花幾篇文章來探討這個主題的原因之一。

• Day-28: 高品質的特性與指標探索 - 維護性
• Day-29: 如何產生指標之SonarQube + 其它

參考書籍與資料

• ISO/IEC 25010
  建立演進式系統架構｜支援常態性的變更 (Building Evolutionary Architectures： Support Constant Change)
• 創新驅動設計：單體與微服務混合架構策略與實踐
• 軟體架構指標｜改善架構品質的案例研究 (Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture)

總結

希望這一系統的文章可以讓在探索維護性這條路的朋朋們 ~ 有個簡單的地圖 ~ 總於完賽了…… 順到說一下我們家的品質很爛，別覺得我在這裡就好，但我們我自已覺得不是工程師的能力問題 ~ 很大的原因是公司整個團隊結構與流程沒有考慮品質這一塊，但也不是說誰對誰錯 ~ 而就只是優先度的問題 ~ 希望接下來能有更多的時間來聊聊這一塊的心得 ~ 完賽 !!!!!!!